It is increasingly common for users having standalone computers, or computers interconnected by an institutional intranet or local area network, to gain access to various remote sites (such as those on the "World Wide Web") via the well-known Internet communications network. Using resident web browser applications executing on the computers, these clients may navigate among services ("pages") stored on various servers of a service provider ("web site") and may further request these services as desired. In a basic network communication arrangement, clients are free to access any remote web site for which uniform resource locators (URLs) are available.
It is also increasingly common in network applications to provide the web site servers with associated proxy cache servers that link ("front-end") the servers with the Internet. A proxy cache server ("proxy") may be used to accelerate client access to the Internet ("forward proxy") or to accelerate Internet access to a web server ("reverse proxy"). As for the latter reverse proxy environment, the proxy may access frequently requested services from the web servers and store ("host") them locally to effectively speed-up access to future requests for the services. For instance, a proxy may host frequently requested web pages of a web site. In response to a request from a browser executing on a client, the proxy attempts to fulfill that request from its local storage; if it cannot, the proxy forwards the request to a web site server that can satisfy the request. The web server then responds by transferring a stream of information to the proxy, which stores and forwards the information over the Internet onto the client. The illustrative embodiment of the invention described herein is applicable to a reverse proxy environment.
As Internet traffic to the web site increases, the network infrastructure of the service provider may become strained attempting to keep up with the increased traffic. In order to satisfy such demand, the service provider may increase the number of network addresses for a particular service by providing additional web servers and/or associated proxies. These network addresses are typically Tranmission Control Protocol/Internet Protocol (TCP/IP) addresses that are represented by URLs or wordtext (domain) names and that are published in a directory service, such as the well-known Domain Name System (DNS). Computers referred to as name servers implement DNS by mapping between the domain names and TCP/IP address(es).
Since the proxies "front-end" the web servers (and may, in fact, be resident on the web servers) in a reverse proxy environment, the network addresses of the proxies (rather than the actual web site) are generally mapped to the domain name of the service provider. As a result, communication exchanges with the proxies generally comprise IP packets or UDP/TCP-socketed traffic, such as socket requests and responses. A socket is essentially an interface between an application layer and transport layer of a protocol stack that enables the transport layer to identify which application it must communicate with in the application layer. For example, a socket interfaces to a TCP/IP protocol stack via a set of application programming interfaces (API) consisting of a plurality of entry points into that stack. Applications that require TCP/IP connectivity typically utilize the socket API to interface into the TCP/IP stack.
For a connection-oriented protocol such as TCP, the socket may be considered a session; however, for a connectionless protocol such as IP datagram using the User Data-gram Protocol (UDP), the socket is an entity/handle that the networking software (protocol stack) uses to uniquely identify an application layer end point, typically through the use of port numbers. The software entity within the server that manages the communication exchanges is a TCP/IP process, which is schematically illustrated as layers of a typical Internet communications protocol stack. Protocol stacks and the TCP/IP reference model are well-known and are, for example, described in Computer Networks by Andrew S. Tanenbaum, printed by Prentice Hall PTR, Upper Saddle River, N.J., 1996.
Thus to access a particular service, a client issues a request to the domain name of the service. A name server receives the request, looks up the domain name and returns all of the mapped (proxy) associated network addresses to the client. The client chooses a first of the addresses directed to a first proxy and sends a service request to that proxy. If the proxy has failed and is "down", the request is ignored; after waiting a period of time, the client may issue another request to that proxy. After sending one or more non-responsive requests to that address, the client may issue a request directed to a second address of a second proxy associated with the service. This time the request may be received and serviced by the second proxy.
Subsequent requests to the particular service may be satisfied as the client selects each of the remaining addresses in, e.g., a round-robin manner, until it comes back to the first address, where a request may again be directed to the first proxy. As long as this proxy is down, though, requests directed to that first network address are ignored. In addition to frustrating the client, such non-responsive requests may prove costly to the service provider in terms of lost revenue and service down-time. As for the latter, adding a new service or expanding an old service of, e.g., a web server may be time consuming and fraught with configuration challenges that typically result in lengthly installations. The present invention is directed to alleviating such time consuming activities and, more specifically, to efficiently increasing the availability of services offered by a service provider.